The present invention relates generally to computer systems which operate in real-time. More particularly, the present invention relates to real-time processors which run JAVA(trademark) programs (JAVA is a trademark of Sun Microsystems, Inc.) and, specifically, to real time processors which can concurrently run several independent JAVA processing machines.
Electronic systems, such as, computerized devices or computer controlled apparatus, are employed in dramatic numbers to perform various operations in diverse applications. These electronic systems range in complexity from simple consumer products, such as, home appliances and children""s toys to complex arrangements, such as, aircraft autopilot systems, chemical processing controls or safety devices for complicated applications. Many of these electronic systems rely on internal, or embedded, computers for at least a portion of their functionality.
Such embedded computer systems often carry out such operations as sensing, computation, display, and control in response to stimuli from internal and external sources. Certain sensing and control applications have demanding speed requirements which can be described as xe2x80x9creal timexe2x80x9d speed requirements. Real time speed requirements demand that the embedded computer system responded to events or stimuli within a strict, specified amount of time. For example, embedded computer systems are utilized in most modern automobiles to control tasks, such as, fuel injection, anti-lock braking, air bag deployment, engine ignition, anti-lock braking, air bag deployment, engine ignition and other operations.
The amount of time allowed for computer response is generally very small. For example, an embedded computer system must rapidly analyze deceleration data to accurately and appropriately deploy an air bag in an automobile. This ability to meet stringent timing requirements often requires that processing resources be available upon demand in a predictable amount of time. Consequently, real-time computer systems typically utilize specialized and complex software to meet real time speed requirements. Many prior art real-time systems have been programmed in relatively xe2x80x9clow-levelxe2x80x9d languages, such as assembly language, so that the programmer can maintain the strict control over the system operation which is necessary to meet the strict time requirements.
A significant consideration in the performance and effectiveness of a real-time computer system is the programming language methodology that is used to create and maintain the software elements that ultimately determine the functionality of the embedded computer system. With present day hardware fabrication costs, the software development costs often far outweigh the hardware costs. Consequently, it would be advantageous to reduce software development and maintenance costs. One problem with programs written in low-level languages is that they are often costly to develop and difficult to maintain.
A wide range of programming methods and languages have historically been used to develop the software elements or programs. The programming methods have ranged from the previously-discussed low level machine specific assembly languages to high level languages which are not specific to a particular hardware element or platform. Generally, high level languages are more efficient in both the design and maintenance of software programs so that their use is particularly advantageous. A broadly emerging type of programming methodology which promises to offer even more favorable efficiencies in program development and maintenance is object oriented programming software design. Object oriented programming software design is based on the concept of extracting particular characteristics from some item of interest along with a set of operations that may be performed on that information and grouping those pieces together to form an object. There are several benefits that may be realized by the implementation of a computer system in an object oriented programming environment. For example, compiler output including both generated program code and symbolic object references may be directly received, stored and integrated into an existing runtime system without further coordination with the already resident program and object references in the system. This capability is of significant value when large programs are created in pieces by large teams of programmers. Currently available object oriented programming languages include ADA 95, C, C++ and JAVA(trademark) languages.
The JAVA programming language was created and propagated by Sun Micro Systems, Inc. to meet the need for an object oriented, platform independent and network enabled programming environment. The JAVA language has been quickly embraced by the computer software community and has been demonstrated to be efficient and robust for a wide variety of general purpose computing applications while generally providing improved development productivity. The successful performance of the JAVA programming language has resulted in a great interest in the use of the JAVA programming language for a wide variety of computing applications, including real time, embedded computing applications.
A program written in the JAVA language is compiled from the JAVA source code into as a series of platform independent commands called xe2x80x9cbytecodes.xe2x80x9d Generally, a JAVA host computer system utilizes a JAVA run time environment to interpret and execute the bytecodes. The JAVA run time environment is called a xe2x80x9cJAVA virtual machinexe2x80x9d (JVM) and it can either interpret the bytecodes directly or use a xe2x80x9cjust-in-timexe2x80x9d compiler to convert the bytecodes to platform dependent codes which run directly on the host platform. The JVM allows a flexible run-time environment.
However, in real-time embedded processor applications, the JVM has some significant drawbacks including speed and difficulty in meeting the strict timing requirements normally found in such environments. Consequently, in such applications, another type of processor is often used in which the JAVA bytecodes generated by a JAVA compiler are executed directly on the platform. In this case, the JAVA bytecodes are the low level assembly language of the processor and the JAVA program could be said to be running on a xe2x80x9cJAVA machinexe2x80x9d rather than on a JVM. Such processors are called xe2x80x9cdirect executionxe2x80x9d JAVA processors.
In the direct execution JAVA processor context, the term JAVA Virtual Machine refers to a logical address space for JAVA classes within which one or more threads can execute. Within such a logical address space, several JAVA applications can concurrently run. Each JAVA application may also create multiple class name spaces by creating one or more class loaders, but, in the absence of application-created class loaders, only one class name space is created by the default class loader in a JVM.
In accordance with normal JVM operation, the JVM assigns each application its own xe2x80x9cruntimexe2x80x9d instance of the class java.lang.Runtime. Therefore, each application has its own runtime system, which both isolates applications from each other and provides a security model. However, the java.lang.Runtime class does not necessarily encompass everything that could be separate for each separate application. If multiple applications each use some of the same classes, a single copy of the static data structures will be created. Without separate JVMs or another class loader, multiple copies of the same static data cannot be created.
Although there may be multiple applications running in a JVM, there are many circumstances when it would be desirable to have multiple JVMs running on a single processor. For example, in an avionics system, there are generally several subsystems which have differing priorities. The flight controller, or the autopilot, have the highest priority (called level 1 priority) whereas other systems, such as in-flight entertainment systems, have a much lower priority (called level 5 priority). The level 1 priority systems are critical and there must be guarantees that such systems are not interrupted or blocked by the lower priority systems. It is also critical that the highest priority systems receive adequate resources to operate properly. Consequently, it would be advantageous to have multiple JVMs running in such an avionics system so that resources in one JVM are completely isolated from resources in another JVM. As stated above, this isolation cannot be guaranteed in systems where several applications are running in a single JVM. The most important resource to isolate is memory. Also, with separate JVMs, if an application in one JVM attempts to use up all the resources, its effect can be contained. In addition, controls must be established so that a first JVM cannot deny service to a second JVM by locking an object that the first JVM also needs to lock.
Another motivation for multiple JVMs on a single processor is to allow different policies for different applications. For example, the range of priorities in one JVM may be higher than for another JVM. Garbage collection strategies might differ, including even the existence of a garbage collector. Different limitations might also apply to different JVMs such as the amount of memory and number of threads.
A final motivation for multiple JVMs on a single processor is to support a partitioning of the application that can later be easily reconfigured to operate on multiple physical chips with separate memory.
The foregoing problems are solved in one illustrative embodiment of the present invention in which multiple JVMs operate on a single direct execution JAVA processor with each JVM operating in a separate time slice called a partition. Each JVM has its own data and control structures and is assigned a fixed area of memory. Each partition is also allotted a fixed period of time in which to operate, and, at the end of the allotted time, a context switch is forced to another JVM operating in the next partition.
In accordance with one embodiment, the context switch does not transfer control directly from one JVM to another JVM. Instead, at the end of a partition time period control is switched from the currently operating JVM to a xe2x80x9cmaster JVMxe2x80x9d during a time period called an xe2x80x9cinterstice.xe2x80x9d The master JVM handles system interrupts and housekeeping duties. At the end of the interstice time period, the master JVM starts a proxy thread associated with the next JVM to become operational. The proxy thread handles JVM-specific interrupts and checks the status of the associated JVM. If the JVM appears operational the proxy thread transfers control to the JVM thread.
In accordance with another embodiment, time intervals such as partition times and interstice times are enforced by hardware timers to prevent a system failure due to a malfunction in either the master JVM or another JVM.
In accordance with still another embodiment, all JVM data structures are referenced by a root JVM address. Thus, the same software can be used to process each JVM by simply changing the root address.
In accordance with yet another embodiment, the memory spaces which are allotted to each JVM are kept separate by hardware address comparison circuitry which checks the address for each read, write or code fetch operation against an address range which specifies the memory location allotted to a JVM. If the address falls outside the allotted range, the operation is not allowed to complete.